Add support for non-string types, LogicalName, ManifestResourceName #9
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Wrote a full .NET fully qualified type name parser using a recursive descent parser * Added support for System.Resources.ResXFileRef resources, which require extra parsing to generate the right code
…to the 2.0 format, fix TypeNameParser to handle assembly names with dots and dashes, add ToCSharp method on ParsedTypeName
…ata on EmbeddedResource items used by the resource compiler to general the internal file name. Without this, we break with any ResX with these values explicitly specified.
ycanardeau
reviewed
Jan 2, 2026
|
|
||
| <PropertyGroup> | ||
| <TargetFramework>net8.0</TargetFramework> | ||
| <TargetFramework>net8.0-windows</TargetFramework> |
Owner
There was a problem hiding this comment.
We could keep TargetFramework as net8.0 and split the tests into two projects: net8.0 and net8.0-windows. That would let the net8.0 tests run in CI.
| @@ -1,107 +1,126 @@ | |||
| <?xml version="1.0" encoding="utf-8"?> | |||
| <root> | |||
| <!-- | |||
Owner
There was a problem hiding this comment.
Indentation was changed from tabs to spaces. Can you please revert this to make the review easier?
| <PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="4.0.1" /> | ||
| <PackageReference Include="Microsoft.CodeAnalysis.Analyzers" Version="3.3.3" /> | ||
| <PackageReference Include="Microsoft.CodeAnalysis.CSharp.Workspaces" Version="4.0.1" /> | ||
| <PackageReference Include="sly" Version="3.7.7" PrivateAssets="all" GeneratePathProperty="true" IncludeInPackage="true" /> |
Owner
There was a problem hiding this comment.
I’d prefer to avoid third-party dependencies where possible. Are there alternatives to using sly?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Thanks so much for the existing work on this project, it's awesome to get source generator support for ResX files instead of the old crusty VS custom tool!
This PR adds support for several missing features that the old VS custom tool had which are blockers for using this source generator with all the traditional use cases for GUI apps.
<EmbeddedResource>items can have LogicalName or ManifestResourceName specified, which affects the internal resource stream name.There was a big blocker in order to accomplish this, which is that we have to parse .NET fully qualified type names from the ResX file without loading the types themselves (since source analyzers use netstandard2.0 which can't depend on WinForms or other frameworks). Weirdly, the .NET BCL doesn't expose its internal type name parser outside of the type loader! So I had to write a parser from scratch using the grammar specified on MSDN: https://learn.microsoft.com/en-us/dotnet/fundamentals/reflection/specifying-fully-qualified-type-names.
I did add a dependency on a Nuget package called sly which implements a lexer and parser framework I used for parsing type names. This library is also licensed under the MIT license so is compatible with using in this project. I added significant unit testing of the parser so I'm confident it handles just about any resource type anyone could come up with. I can appreciate if fully parsing the type name seems like overkill, but after trying a few simpler approaches and running into issues with common ResX files (some types are fully qualified with the assembly, others aren't, etc.), I figured it would be the only foolproof approach.
Beyond the type name parser, I've added several new test cases to validate that non-string types work properly and LogicalName is respected. I added 3 new diagnostic messages to cover cases where the ResX type is invalid or unsupported.
This would resolve #2 and #10